Traditional security systems assume that one or more systems are always secure, i.e. are never controlled by the attackers. The model of Proactive Security does not make this assumption. Instead, it considers cases where all components of the system may be broken-into and controlled by an attacker, with restrictions on the number of components broken-into during the same time periods (day, week, . . . ).
Proactive security shows how to maintain the overall security of a system even under such conditions. In particular, it provides automated recovery of the security of individual components, avoiding the use of expensive and inconvenient manual processes (except for some “aggressive” attacks, which cannot be prevented—but are definitely and clearly detected). The technique combines two well-known approaches to enhance the security of the system: distributed (or threshold) cryptograph, which ensures security as long as a threshold (say half) of the servers are not corrupted and periodic, refresh (or update) of the sensitive data (e.g. keys) held by the servers. In short,Proactive=distributed+refresh 
This way, the proactive approach guarantees uninterrupted security as long as not too many servers are broken at the same time. Furthermore, it does not require identification when a system is broken into, or after the attacker loses control; instead, the system proactively invokes recovery procedures every so often, hoping to restore security to components over which the attacker lost control.
Proactive security is highly desirable in many realistic settings, in particular:    When a high level of security is required, together with fault tolerance (as redundancy improves fault tolerance but opens more points for attack).    To ensure acceptable level of system using weakly secure components such as most commercially available operating systems.Recent results show that many fundamental cryptographic functionalities may be achieved even under the proactive security model—as long as most components are secure most of the time. In particular, proactively secure protocols have been devised for the following problems (see General Overview in [2]:    Secret sharing    Discrete-log-based digital signatures, and in particular DSA    Secure and end-to-end communication    RSA and in particular generation of the RSA shared key Pseudo-random generation    Key distribution center    This substantial set of known results in proactive security did not yet produce any practical security product or solution. (In fact, there are only a few developments of distributed security—the most well known may be the SET credit card standard\s certificate authority; see also ‘related art’ below). The creation of such a proactive solution is non-trivial, as the protocols are often quite complex and nontrivial to implement. Furthermore, the protocols are specified under some simplifying assumptions and do not address some needed elements, such as interfacing between the proactive service and the applications using it.Applications of the Proactive Security ServicesThere are three kinds of applications that may take advantage of the proactive security services, as follows:    Centralized applications—a “traditional” application running on one server only. The application uses a proactively secure service provided by the toolkit. For some applications and services, this could provide a significant advantage, at minimal change to existing applications. Some typical applications are:            Secure logging: each client application may add entries (events) to the log; however, none of them can modify or erase the log. This could be of great value in improving intrusion detection tools, as intruders often try to erase traces in log files.        Secure end-to-end communication: the proactive environment can provide the applications with freshly generated and certified public keys periodically. This could be integrated with tunneling mechanisms such as secure IP or SSL.        Timestamping: can be used to sign a document (or its hash) and current time, to prove that the document existed at this time.            Distributed applications—the application runs simultaneously on all servers (App_1 . . . , App_n) and requests services through all servers. Each App I interacts directly with its own proactive server (PS-I). A typical application is a certificate authority, or in general any workflow application requiring secure (multi-person) digital signatures. Another application is key recovery (escrow agents).    Proactive applications—the application runs in a distributed configuration but, in addition, goes through periodical refreshes by utilizing the proactive services. This is required when the application security or efficiency requirements cannot be met by the services. Examples include multiparty protocols such as voting and trading, database, operating system and access control mechanisms. Another application is a Secure Commerce Server—such server cannot lie behind the firewall although it handles confidential data and matters (such as access control, certificates, etc.), it is therefore natural to proactively distribute the server among a number of (independent, and possibly not even mutually trusted) hosts and locations thus achieving increased trust in the server.Related Art: